feat: allow session config changes during a running turn - #3715

Could you help clarify the product motivation for this pending configuration feature? I want to make sure the complexity is well justified:

1. What is the concrete high-frequency workflow where changing model/thinkingLevel/permissionMode during a running turn is needed, and what is the real cost compared to "wait until the current turn finishes and then switch"?

2. Why does the pending selection need to be durable and synchronized across restarts, reconnects and multiple clients, rather than a lighter local best-effort staging (e.g. client memory) that is dropped on reload?

3. After the change, the controls immediately show the new values while the current Turn still runs with the old configuration, with no explicit "will take effect next turn" indicator. How is the user expected to reliably understand this, and what is the basis for that (e.g. existing pattern, user study, or prior design)?

Thanks for the review. I pushed commit 06052df with the requested fix. Root-Turn admission now catches SessionConfigurationTransitionError and returns the corresponding typed outcome (session_busy, operation_conflict, or operation_unavailable); unknown errors are still rethrown so the existing fail-stop behavior is preserved. Pending state remains persisted when application fails, and a regression test covers this path. I also fixed Runtime SessionManager summaries so pendingConfiguration remains visible to direct consumers. Product rationale: this is preparation for the next turn, not hot-swapping the active provider request. A common case is a long-running analysis, build, test, or tool-heavy turn where the user already knows the next request needs a different model, thinking level, or permission mode; waiting for the current turn adds avoidable latency, especially when a follow-up is queued. The pending selection is Host-owned Session state because the successor may be submitted by another client or admitted after reconnect/restart; renderer-local state could be lost or disagree with another client. The issue intentionally keeps the existing controls as the single configuration surface, without a separate current/next panel or persistent badge: the active AgentRun keeps its immutable snapshot, and the latest Host-authoritative value is consumed at the next root-Turn admission. This is an explicit product trade-off from the issue, not a claim based on a user study. Targeted verification on this head: SessionManager 225 passing; Root Turn Coordinator 50 passing. 中文摘要：已修复 pending 配置应用失败未返回 typed outcome 的问题；当前任务不会热切换，运行中的选择只在下一轮 root Turn admission 时生效，并由 Host 持久化以保证重连、重启和多客户端一致性。